Is there a chance SuggestedStartLocationDirectory will be added, where you can provide any string file path (e.g. if SuggestedStartLocation == PickerLocationId.Unspecified)? (see #4942 (comment))

It would be a bummer if this limitation, that only applies to the UWP picker and UWP apps and not the COM picker, would be retained. From history, if it's not being addressed now, it will forever stay like that :/

btw: It's certainly a feature that would be much appreciated as @whiskhub said. There is a quite popular issue dotnet/maui#9212 on the MAUI side asking for this feature. A person did a great research into it here.

I agree, a SuggestedStartLocationDirectory would be very useful. If you don't implement that, please at least implement the SettingsIdentifier, otherwise the start location will be even less customizable than in UWP.

Hi WinAppSDK friends @whiskhub , @MartyIX , @benstevens48 .

The string input of SuggestedStartLocation feature is on our wishlist for future milestones. For the first version of Microsoft.Windows.Storage.Pickers, we aim to implement method signatures consistent with Windows.Storage.Pickers and will not add new signatures at this time.

and will not add new signatures at this time

You are, to a degree, as the spec is a consistent subset of Windows.Storage.Pickers - no PickMultipleFilesAsync(), CreateForUser(), etc. Why the omissions if consistency is a goal?*

* I can see why the Continue properties/methods are omitted. It's the others I find puzzling if consistency is the goal.

I am just afraid that "wishlist for future milestones" practically means "never" 😅 which means I'd "never" be able to use this picker :/

What's the behavior?

"An unspecified location" means the caller doesn't specify something. So what's the behavior when this occurs?

Thanks @DrusTheAxe , I will add more details in the spec.
An unspecified location means that the file picker does not preset any specific storage location, allowing the user to choose the storage location themselves.

PS: The values here are consistent with Windows.Storage.Pickers.PickerLocationId

DocumentsLibrary = 0 means this is the default behavior?

DocumentsLibrary = 0 means this is the default behavior?

Yes and no. For the enum itself, indeed it is 0 when not specified.
However, in the code of our new pickers, all 3 pickers set the default location as Unspecified.
We will implement:

struct FileOpenPicker : FileOpenPickerT<FileOpenPicker>
{
    private:
        // ... 
        PickerLocationId m_suggestedStartLocation{ PickerLocationId::Unspecified };

You can find detailed code on dev branch: https://github.com/microsoft/WindowsAppSDK/blob/user/xianghong/storage-pickers-develop/dev/Interop/StoragePickers/FileOpenPicker.h

If Unspecified is the default why is the value for Unspecified != 0

Defaults don't have to be 0/false/null but it's convenient. As this is new APIs with new types seems the default could have a value of 0. Is there a specific reason it doesn't or can't?

P.S. Regardless the answer the spec needs an update specifying the default behavior.

Where is Specified option? How do I provide an arbitrary path of my choosing?

Start location should be specifiable as a string

string path = GetPathIWantUseAsAString();
var openPicker = new FileOpenPicker(this.AppWindow.Id);
openPicker.SuggestedStartPath = path;
var file = await openPicker.PickSingleFileAsync();

Optionally it can also be specified as a StorageFolder

StorageFolder folder = GetPathIWantUseAsAStorageFolder();
var openPicker = new FileOpenPicker(this.AppWindow.Id);
openPicker.SuggestedStartFolder = folder;
var file = await openPicker.PickSingleFileAsync();

And if 2+ are specified what happens?

SUGGESTION: Given location (enum) + path (string) + folder (StorageFolder) if 2+ are specified they must be consistent when PickSingleFolderAsync/etc are called or E_INVALIDARG

Why a predefined enum rather than a string (or string + StorageFolder)?

Windows.Storage.KnownFolders has 13 properties for predefined / 'well known' locations.

The list here was 10 (+'Unspecified') but only 6 in common with KnownFolders (7 missing).

KNOWNFOLDERID used by SHGetKnownFolderPath supports 129 locations.

CONSIDER: Replacing the enum with string SuggestedStartPath, and maybe also supporting StorageFolder SuggestedStartFolder. See other comment for more details.

A current "UWP (AppContainer) app" may not have the Videos Library capability, but can still open a file picker in the Videos Library using this enum. Setting a SuggestedStartFolder directly using KnownFolder.VideosLibrary would throw access denied however.

So, probably some kind of enum must stay for AppContainer apps.

1. UWPs/(aka CoreWindows).
2. AppContainer.
3. MSIX.

are totally three independent things altogether.

(#4844 (comment) + microsoft/winget-cli#4260 (comment))

but can still open a file picker in the Videos Library using this enum

Oh? That's interesting. Why?

Because the picker is interactive so OK on the prompt implicitly has user consent? If the app wants to access a location which normally requires an AppContainer to declare a capability but the user interactively navigates there that's OK as it implies user consent?

Oh? That's interesting. Why?

I can only guess, since I am not a Microsoft employee. 😅

auto path{ folder.Path() };

ES.23: Prefer the {}-initializer syntax

You provided a C# example. Why also a C++ example?

The norm is a C# example and only add other languages if they pose additional or different needs beyond mere syntax. Here' the C# and C++ examples are the same just language syntax differences.

Hi @DrusTheAxe

The reason for including both C# and C++ examples in the documentation is to cater to a broader audience. While the examples may only differ in syntax, providing both versions can help developers who are more comfortable with one language over the other.

This approach is not unique to our specs. We have several other documents that provide examples in both languages, such as the CameraCaptureUI.md

I think c# is preferable to csharp as it's supported by more environments (GitHub, ADO, VSCode, ...)

@codendone do you recall that conversation we had. Did it end with c# is the best choice or am I misremembering?

same comment applies throughout

WinRT APIs should be defined as MIDL3.

Examples are written in specific languages (usually C#). Non-WinRT APIs are defined in their specific language, in the rare event a WinAppSDK API isn't WinRT.

RECOMMEND: Define as MIDL3, not any specific language

namespace Windows.Storage.Pickers
{
    Windows.Foundation.IAsyncOperation<Windows.Storage.StorageFolder> PickSingleFolderAsync();
}

The spec is split across multiple files, with their definitions (IDL) likewise split across multiple files. This complicates reviewing (and holistically understanding) the design and details.

Do you intend to have multiple .idl files in the implementation?

CONSIDER: Moving all the definitions to a single file, ideally as an # API section in Microsoft.Windows.Storage.Pickers.md

...
# API

```c# (but really MIDL3)
namespace Windows.Storage.Pickers
{
    ...
}

That will also address gaps e.g. where's the API contract details?

The comment should be 'Returns null if the file dialog was cancelled or closed without selection.'